9 תשובות
ענה
זה לא יהיה טוב, לא בגלל שהמחלקה תהיה גדולה, אלה בגלל שיהיו בה דברים שלא צריכים להיות בה.
תפרק אותה למחלקות קטנות עד כמה שאפשר.
מבחינת מהירות פיענוח לא תהיה שום בעיה. באיחוד עם מותקן לך APC על השרת.
ענה
מדובר בסוג מסוים של תוכן (מתכון, למען האמת XDDD), שיש לו המון getters, setters (וגם כמה unsetters), כמו גם כל מיני דברים כמו יצירת אחד נוסף.
אני חושב על לחלק את זה לשני חלקים שיירשו ממחלקה אחת (פונקציונליות שונה למדי בין הגרסה הראשונה של מתכון לבין שאר הגרסאות שלו), שלא לדבר שכבר יש לי עוד חלק נפרד (שאמור להיות נפרד גם ככה), של חיפוש חכם של התוכן הזה.
אבל המחלקה האחת ההיא (בתחילת המשפט) עדיין תהיה גדולה.
נ.ב. אני מניח שהבעיה העיקרית באורך היא ה-getters וה-setters. סביר להניח שאפשר איכשהו לאחד אותם לכמה מתודות בודדות. רעיונות?
מעדיף לא לגשת ישירות למשתנים, גם אם זה לא באמת ככה.
אבל כמו שאמרתי, אני מניח שאפשר לעשות משהו כמו:
כך שזה יהיה גמיש יותר (הפרמטר הראשון קובע את מה לשנות, והבאים הם הערך/ים).
אבל כל זה לא באמת משנה כרגע.
הבעיה היא שזה ייקח הרבה תנאים, כי זה לא בדיוק השם של העמודה בבסיס הנתונים, ויש גם מסננים שונים בדרך וכדו'. כמו שאמרתי, חלק מהפונקציונליות משותף וחלק שונה. מה עושים במקרה כזה?
מה שהתכוונתי היה יותר הפסקה האחרונה שכתבתי. גם אם השתמשתי ב-magic method, זה עדיין היה קורה.
אבל כמו שאמרתי, לא סתם שמתי את הגטרים וסטרים בנפרד - יש להם פונקציונליות נפרדת (לא סתם לשים ישירות במסד ולשמור במשתנה), אז מה, אני אעשה עכשיו switch case של 20-30 מקרים? זה אפקטיבי?